Review changes with  

Changed Files

File	Status
packages/studio-web/tests/studio-web/download-web-bundle.spec.ts	58% smaller
packages/studio-web/tests/test-commands.ts	51% smaller
packages/studio-web/src/i18n/messages.es.json	43% smaller
packages/studio-web/src/i18n/messages.fr.json	43% smaller
packages/studio-web/src/i18n/messages.json	35% smaller
packages/studio-web/src/app/editor/editor.component.html	24% smaller
packages/studio-web/src/app/editor/editor.component.ts	2% smaller
packages/studio-web/src/app/app.module.ts	0% smaller
packages/studio-web/src/app/demo/demo.component.html	0% smaller
packages/studio-web/src/app/demo/demo.component.ts	0% smaller
packages/studio-web/src/app/editor/editor.component.sass	Unsupported file format
packages/studio-web/src/app/shared/download/download.service.ts	0% smaller
packages/studio-web/src/app/shared/wc-styling/wc-styling-helper.html	0% smaller
packages/studio-web/src/app/shared/wc-styling/wc-styling.component.html	0% smaller
packages/studio-web/src/app/shared/wc-styling/wc-styling.component.sass	Unsupported file format
packages/studio-web/src/app/shared/wc-styling/wc-styling.component.spec.ts	0% smaller
packages/studio-web/src/app/shared/wc-styling/wc-styling.component.ts	0% smaller
packages/studio-web/src/app/shared/wc-styling/wc-styling.service.ts	0% smaller
packages/studio-web/src/app/studio/studio.component.ts	0% smaller
packages/studio-web/tests/editor/custom-css.spec.ts	0% smaller
packages/studio-web/tests/editor/download-web-bundle.spec.ts	0% smaller
packages/studio-web/tests/fixtures/CutiveMono-Regular.ttf	Unsupported file format
packages/studio-web/tests/fixtures/cour.ttf	Unsupported file format
packages/studio-web/tests/fixtures/sentence-paragr-cust-css.css	0% smaller
packages/studio-web/tests/fixtures/sentence-paragr-cust-css.html	0% smaller
packages/web-component/README.md	Unsupported file format
packages/web-component/src/components.d.ts	0% smaller
packages/web-component/src/components/read-along-component/read-along.tsx	0% smaller
packages/web-component/src/components/read-along-component/readme.md	Unsupported file format
packages/web-component/src/scss/modules/_settings.scss	Unsupported file format
update-translations.sh	Unsupported file format

First impressions: this is great, being able to add fonts and styling. In the Editor, it's good to have it shown below the wavesurfer view. In the Studio, I feel it's a bit too much in your face, for something I expect some users will be excited about, and some users will just want to ignore. Could we have an arrow thing to make showing the Styling editor optional, with the default being close in Studio?

I ran a couple tests and it works for me and made the interface pink with the example provided in one example :-)

To add a comment , can we have the default pre-written in the window ... For example when I start typing in the CSS section, the "example" provided will erase / I can't copy and paste the "grey" example as the initial template ( If this makes sense what I am saying...)

I ran a couple tests and it works for me and made the interface pink with the example provided in one example :-)

To add a comment , can we have the default pre-written in the window ... For example when I start typing in the CSS section, the "example" provided will erase / I can't copy and paste the "grey" example as the initial template ( If this makes sense what I am saying...)
Thanks for the review !

If you clicked the help button, you would have seen a sample stylesheet.
@joanise should we prefill the style?

If you clicked the help button, you would have seen a sample stylesheet.
@joanise should we prefill the style?

I would say not by default. By default, the style sheet should be empty. But we could have a button that populates it with the template that has all the things you can specify, that would be really helpful.

Looks good from my side!

As discussed elsewhere, this is good but we would like to do more testing and a more careful review of the code, and maybe polish the interface, so we'll postpone full review merging until after ICLDC.

@joanise I need translation help

Hmm, when you have a wide screen but a narrow readalong, the ratio is really weird:

There are a number of different screen widths where it's not longer behaving like before, I would like to preserve the nice sizing we had settled on, and have this thing just use a small bit of real estate on the side when it's not expanded.

Hmm, when you have a wide screen but a narrow readalong, the ratio is really weird:

There are a number of different screen widths where it's not longer behaving like before, I would like to preserve the nice sizing we had settled on, and have this thing just use a small bit of real estate on the side when it's not expanded.

Did you resize the style window? I have modified the code to reset any resizing after you collapse the window

Wow — this is a lot of work (and it works!). Nicely done!

I’ve left a few comments — most are very minor — and flagged a couple of smaller UI issues with screenshots that I think we should fix before merging.

One more general thought: I wonder whether it’s worth stepping back for a moment to think about whether building a full-fledged code/CSS editor directly in RAS is the right direction long term. When testing the input area, I found it a bit difficult to edit CSS without syntax highlighting, but adding syntax highlighting might edge us further into scope creep (i.e. developing our own in-browser code editor).

The point of the editor is to have a way to preview CSS code you are developing with an IDE. There are very good CSS editors available, so we won't attempt to create one. However, after you have created your custom style sheet, you need a way to "quickly" preview your changes that is component seek to do

I will add a copy and paste button so it is easy to transfer the style between your editor and the box.

A couple of alternative directions that might be worth considering down the line:

Option A: Rather than having an open CSS input field, we could support uploading CSS files and link users to an external editor (e.g., CodePen) that supports SCSS, syntax highlighting, etc.

Option B: Alternatively, we could narrow the focus to theming (e.g., light/dark foreground/background colours). Users could choose colours via a picker, and we’d generate the CSS under the hood. Not sure if that would fully support your use case, but it might simplify the UX.

I am in favour of this option as an add-on (feature for the future, step one is #420, then #438). This will be a use case for your basic user, and the advanced user will use the pattern I described above.

To be clear, I’m not suggesting these as replacements for this PR — just possible future directions that could help keep things streamlined while still giving users flexibility. Happy to chat more if helpful!

Thanks for the thoughtful review. I will incorporate the necessary changes!